Filter initialization issue

I have a script that first, turns off filtering to clear whatever the user may have, then creates a new filter, and turns filtering on.

The issue is when a module a first opened, and there is no filter, the script is not able to "turn on" the created filter.  It's properly created, but you have to manually enable it.

Every subsequent run of the script, it properly creates and enables the filter.  It's just the first run that doesn't.  What's going on?

If you need to see code, it's basically just this:

Filter f,f1,f2

filtering off

for o in m do {

f1 = isNull("attributeX")

f2 = isNull("attributeY")

f = (f1 && !f2)

set (m,f)

}

filtering on

Re: Filter initialization issue
Tony_Goodman - Wed Aug 27 03:53:05 EDT 2014

You don't need the object loop. Filters implicitly apply to all objects.

I can't explain why your code didn't work the first time round though.

Filter f,f1,f2

filtering off

f1 = isNull("attributeX")

f2 = isNull("attributeY")

f = (f1 && !f2)

set (m,f)

filtering on

Re: Filter initialization issue
llandale - Wed Aug 27 15:30:41 EDT 2014

The object loop is worse than "needless", it is destructive.  The "set" command inside the loop will affect which objects are currently viewed, effectevly modifying the loop.   No telling what may happen in that case, but an apparently failed filter may be one of them.  I wonder what happens if you filter out the loop object?

Its a good habit to insert the following about the "fitlering off" command; the "current" module changes more frequently than you'd guess.

• current = m

-Louie

Re: Filter initialization issue
bucket - Wed Aug 27 15:43:37 EDT 2014

I moved the filter out of the loop.  Same result.

And the script starts with:

Module m = current

I'm using version 9.3, by the way.  Maybe someone could try it in a more recent build?

Re: Filter initialization issue
llandale - Wed Aug 27 16:10:50 EDT 2014

Hope you mean deleted the object loop as Tony showed.

Is there anything between "Module m = current" and the start of your code above "Filter f..."?  Perhaps opening some other modules?

This is an on-demand script, run perhaps from a menu?

-Louie

Re: Filter initialization issue
GregM_dxler - Wed Aug 27 16:21:32 EDT 2014

Maybe try adding a refresh m command after setting the filter.

Had a problem one time where it looked like it didn't apply the filter and adding in the refresh helped it.

Probably not the solution, but I just started the habit to always do a refresh after a set or after a loop of apply/reject objects just in case...

Greg

Re: Filter initialization issue
bucket - Wed Aug 27 16:30:56 EDT 2014

Yes, I'm running this from the menu.  I set it up to check for common errors in a module.  I said moved, because there's other functions that require the loop.

Hrm..  I just tried stripping it down to just the filter like :

Filter f,f1,f2

Module m = current
filtering off

f1 = isNull(attribute "Object Text")

f2 = isNull(attribute "Object Heading")

f = (f1 && !f2)

set (m,f)

filtering on

And it works fine in a newly opened module.  I must be something I'm doing elsewhere.  Thanks for the tips.

Re: Filter initialization issue
llandale - Thu Aug 28 16:12:46 EDT 2014

My track record isn't good for debugging code that I don't know what it does and cannot see it.  Although I have had a little success at that... ;)

Post the code, or a large chunk of it before the above code.

There is another solution of course; which I do all the time.  Don't use the "Filter":

• for o in entire mod do
• {  if (isDeleted(o))      then continue
•    if (table(o) or row(o) or cell(o))    then continue   // Ignore objects in tables
•    if (!null (o."Object Text" "") or null (o."Object Heading" ""))  then  continue
•    CheckThisObject(o)
• }

This loop finds all objects.  I hate being at the mercy of views and filters, and in years past you had to open the module visibly to use them.  So, in fact, I NEVER use a "Filter"; unless I'm about to save it in a view.

-Louie

Re: Filter initialization issue
bucket - Thu Aug 28 16:32:22 EDT 2014

Sorry, I just figured the "guts" of the code was inconsequential.

I do appreciate the help, and I'm now convinced the problem is with my arrangement of the refresh, current, setFocus, set, and filtering at the end of the script.

It's difficult to troubleshoot though, because the issue only occurs the first run in a module.  I'm not sure what makes that unique.

Possibly an issue with this part?

// Load linked modules
LinkRef lr
ModName_ otherMod = null
string linkModName = "*"
Object firstObj = first(m)

for lr in all(firstObj <- linkModName) do {
 otherMod = module (sourceVersion lr)
 if (!null otherMod) {
  if ((!isDeleted otherMod) && (null data(sourceVersion lr))) {
   load((sourceVersion lr),false)
  }
 }
}

Re: Filter initialization issue
llandale - Fri Aug 29 13:29:14 EDT 2014

Error the 1st time you open a module is often a "current" module problem; explaining my original response.

It is very difficult to figure out exactly when "current" changes, but the following is relevant when you issue a read/share/edit command:

• If that module is already open, current doesn't change; at least the vast majority of the time.
• If that module is not already open, it becomes the current.  At least most of the time.
• Be advised that upgrading a module, say from read to edit, DOES re-open the module.

So if your default view has layout or attr dxl that follows links,some other module is likely to be the "current" one.  However, since those modules tend to stay open, the 2nd time you open this module it remains "current".  I also notice your "load" command above, which may also change the current module.

There is a plethora of nuances and exceptions of setting "current", and I gave up trying to figure it out during v7 of DOORS.  So, with predicting "current" out of the question, commands that presume the current module (such as filtering on) should be preceded by current = mod; thus resolving the problem.  Several "attribute" commands have a similar requirement.

-Louie